… Step 1 (#411)

The only post-install "verification" was a log-only, failure-masking
interpolation, so a corrupt or wrong-architecture binary (winget shims /
partial installs skip checksum verify; brew delivers with no checksum of ours)
still printed "System tools" and only died at cluster-create in Step 2.
All three OSes had the gap.

- New shared execute-gate helpers: assert_tool_runs (common.sh, bash) and
  Assert-ToolRuns (install-k8s.ps1, PowerShell). Each runs the tool's self-check;
  on non-zero exit or an exception it removes the located binary and fails loudly
  with an arch-aware remedy, so the tool step fails instead of the cluster step.
- Gate kubectl / k3d / helm after install on Linux (setup-linux.sh), macOS
  (setup-macos.sh), and Windows (install-k8s.ps1), on both the fresh-install and
  already-present paths. "System tools" success only prints once all gates pass.
- kubectl is gated with `version --client` (NOT --short — removed in kubectl
  1.28+, which would false-fail the gate).
- New check-drift.sh parity check (_drift_execute_gates) so no installer can
  silently drop a gate for a tool.

Tests: +2 bats (common — working tool passes / broken tool errors + removes the
binary), +2 bats (drift parity), +7 Pester (exit-nonzero / exception /
binary-removal / arch remedy / static gates).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…-gate (#411)

The execute-gate (#411) runs `<tool> version` after install, but the
setup-linux.bats harness only marked tools "present" via has() — it never
provided a RUNNABLE k3d/kubectl/helm. On the toolless CI runner the gate's
probe found no binary and failed 4 install_k3d tests; locally it false-passed
because a real k3d was on PATH. Add silent (non-recording) runnable stubs to
setup() so the gate has something to execute and they shadow any real tool on a
dev host. Test-only; no production change.

…on; drift extracts calls (review #411)

Three review findings on #411 (saadqbal + Bugbot):

- Execute-gate deleted the wrong binary on the already-present path. Removal is now
  OPT-IN via `assert_tool_runs --rm <path>` / PS `-BinPath`, passed ONLY by the
  fresh-install callers that placed the binary. On the present / brew / winget path
  we don't pass it, so a broken pkg-managed binary is left in place (deleting a brew
  symlink just wedges the re-run, and the bad copy may be elsewhere on PATH). bash:
  --rm on Linux fresh-install, none on present or macOS/brew. ps1: -BinPath tracks
  the direct-download dest ($null for winget/present).
- helm was gated with `version --short`; --short can be dropped like kubectl's was,
  which would false-fail the gate and (previously) delete a good binary. Use bare
  `helm version` on all three OSes.
- _drift_execute_gates used a whole-file grep that could match comments. It now
  strips comment lines and matches the actual call (`assert_tool_runs … <t> version`
  / `Assert-ToolRuns -Name "<t>"`), handling the new --rm form. (no grep -q under
  pipefail — SIGPIPE would false-fail.)

Tests: common.bats split into --rm-removes vs no-rm-leaves; check-drift.bats adds
--rm-form + commented-out-gate cases.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…d it AND it ran (Bugbot #411 r2)

Round-1 made removal opt-in but only on the fresh-install path, so a broken
installer-placed kubectl/k3d on the ALREADY-PRESENT path (left by a prior run)
stayed → `has` true → re-run couldn't self-heal (Bugbot). helm already handled it.

Unify all three: callers pass --rm "$TB_TOOLS_DIR/<tool>" (bash) / -BinPath
"$TOOL_DIR\<tool>.exe" (ps1) on EVERY path, and the gate removes that path only
when the binary that actually ran resolves to it — `command -v … -ef <path>` on
bash, `(Get-Command).Source -eq $BinPath` on ps1. So a broken copy we own (fresh
or prior-run) self-heals, while a brew/winget/pkg-manager copy elsewhere on PATH
is never touched (satisfies the earlier reviewer guard too). Dropped the now-moot
$k3dDest/$helmDest null-tracking and helm's -f branch.

Tests: common.bats +decoy-copy case; install-k8s.Tests.ps1 removal split into
ran-here (removed) vs resolved-elsewhere (left); check-drift already covers --rm.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>